home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc2136.txt < prev    next >
Text File  |  1997-05-01  |  56KB  |  1,460 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  P. Vixie, Editor
  8. Request for Comments: 2136                                          ISC
  9. Updates: 1035                                                S. Thomson
  10. Category: Standards Track                                      Bellcore
  11.                                                              Y. Rekhter
  12.                                                                   Cisco
  13.                                                                J. Bound
  14.                                                                     DEC
  15.                                                              April 1997
  16.  
  17.          Dynamic Updates in the Domain Name System (DNS UPDATE)
  18.  
  19. Status of this Memo
  20.  
  21.    This document specifies an Internet standards track protocol for the
  22.    Internet community, and requests discussion and suggestions for
  23.    improvements.  Please refer to the current edition of the "Internet
  24.    Official Protocol Standards" (STD 1) for the standardization state
  25.    and status of this protocol.  Distribution of this memo is unlimited.
  26.  
  27. Abstract
  28.  
  29.    The Domain Name System was originally designed to support queries of
  30.    a statically configured database.  While the data was expected to
  31.    change, the frequency of those changes was expected to be fairly low,
  32.    and all updates were made as external edits to a zone's Master File.
  33.  
  34.    Using this specification of the UPDATE opcode, it is possible to add
  35.    or delete RRs or RRsets from a specified zone.  Prerequisites are
  36.    specified separately from update operations, and can specify a
  37.    dependency upon either the previous existence or nonexistence of an
  38.    RRset, or the existence of a single RR.
  39.  
  40.    UPDATE is atomic, i.e., all prerequisites must be satisfied or else
  41.    no update operations will take place.  There are no data dependent
  42.    error conditions defined after the prerequisites have been met.
  43.  
  44. 1 - Definitions
  45.  
  46.    This document intentionally gives more definition to the roles of
  47.    "Master," "Slave," and "Primary Master" servers, and their
  48.    enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
  49.    following server type definitions can be considered an addendum to
  50.    [RFC1035], and are intended to be consistent with [RFC1996]:
  51.  
  52.       Slave           an authoritative server that uses AXFR or IXFR to
  53.                       retrieve the zone and is named in the zone's NS
  54.                       RRset.
  55.  
  56.  
  57.  
  58. Vixie, et. al.              Standards Track                     [Page 1]
  59.  
  60. RFC 2136                       DNS Update                     April 1997
  61.  
  62.  
  63.       Master          an authoritative server configured to be the
  64.                       source of AXFR or IXFR data for one or more slave
  65.                       servers.
  66.  
  67.       Primary Master  master server at the root of the AXFR/IXFR
  68.                       dependency graph.  The primary master is named in
  69.                       the zone's SOA MNAME field and optionally by an NS
  70.                       RR.  There is by definition only one primary master
  71.                       server per zone.
  72.  
  73.    A domain name identifies a node within the domain name space tree
  74.    structure.  Each node has a set (possibly empty) of Resource Records
  75.    (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
  76.    Resource Record Set (RRset).
  77.  
  78.    The pseudocode used in this document is for example purposes only.
  79.    If it is found to disagree with the text, the text shall be
  80.    considered authoritative.  If the text is found to be ambiguous, the
  81.    pseudocode can be used to help resolve the ambiguity.
  82.  
  83.    1.1 - Comparison Rules
  84.  
  85.    1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
  86.    RDLENGTH and RDATA fields are equal.  Note that the time-to-live
  87.    (TTL) field is explicitly excluded from the comparison.
  88.  
  89.    1.1.2. The rules for comparison of character strings in names are
  90.    specified in [RFC1035 2.3.3].
  91.  
  92.    1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
  93.    update only matches a wildcard ("*") in the zone, and vice versa.
  94.  
  95.    1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
  96.    the update, and will not otherwise be followed.  All UPDATE
  97.    operations are done on the basis of canonical names.
  98.  
  99.    1.1.5. The following RR types cannot be appended to an RRset.  If the
  100.    following comparison rules are met, then an attempt to add the new RR
  101.    will result in the replacement of the previous RR:
  102.  
  103.       SOA    compare only NAME, CLASS and TYPE -- it is not possible to
  104.              have more than one SOA per zone, even if any of the data
  105.              fields differ.
  106.  
  107.       WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
  108.              -- only one WKS RR is possible for this tuple, even if the
  109.              services masks differ.
  110.  
  111.  
  112.  
  113.  
  114. Vixie, et. al.              Standards Track                     [Page 2]
  115.  
  116. RFC 2136                       DNS Update                     April 1997
  117.  
  118.  
  119.       CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
  120.              to have more than one CNAME RR, even if their data fields
  121.              differ.
  122.  
  123.    1.2 - Glue RRs
  124.  
  125.    For the purpose of determining whether a domain name used in the
  126.    UPDATE protocol is contained within a specified zone, a domain name
  127.    is "in" a zone if it is owned by that zone's domain name.  See
  128.    section 7.18 for details.
  129.  
  130.    1.3 - New Assigned Numbers
  131.  
  132.       CLASS = NONE (254)
  133.       RCODE = YXDOMAIN (6)
  134.       RCODE = YXRRSET (7)
  135.       RCODE = NXRRSET (8)
  136.       RCODE = NOTAUTH (9)
  137.       RCODE = NOTZONE (10)
  138.       Opcode = UPDATE (5)
  139.  
  140. 2 - Update Message Format
  141.  
  142.    The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
  143.    are necessary (for example, more error codes are possible under
  144.    UPDATE than under QUERY) and some fields must be overloaded (see
  145.    description of CLASS fields below).
  146.  
  147.    The overall format of an UPDATE message is, following [ibid]:
  148.  
  149.       +---------------------+
  150.       |        Header       |
  151.       +---------------------+
  152.       |         Zone        | specifies the zone to be updated
  153.       +---------------------+
  154.       |     Prerequisite    | RRs or RRsets which must (not) preexist
  155.       +---------------------+
  156.       |        Update       | RRs or RRsets to be added or deleted
  157.       +---------------------+
  158.       |   Additional Data   | additional data
  159.       +---------------------+
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Vixie, et. al.              Standards Track                     [Page 3]
  171.  
  172. RFC 2136                       DNS Update                     April 1997
  173.  
  174.  
  175.    The Header Section specifies that this message is an UPDATE, and
  176.    describes the size of the other sections.  The Zone Section names the
  177.    zone that is to be updated by this message.  The Prerequisite Section
  178.    specifies the starting invariants (in terms of zone content) required
  179.    for this update.  The Update Section contains the edits to be made,
  180.    and the Additional Data Section contains data which may be necessary
  181.    to complete, but is not part of, this update.
  182.  
  183.    2.1 - Transport Issues
  184.  
  185.    An update transaction may be carried in a UDP datagram, if the
  186.    request fits, or in a TCP connection (at the discretion of the
  187.    requestor).  When TCP is used, the message is in the format described
  188.    in [RFC1035 4.2.2].
  189.  
  190.    2.2 - Message Header
  191.  
  192.    The header of the DNS Message Format is defined by [RFC 1035 4.1].
  193.    Not all opcodes define the same set of flag bits, though as a
  194.    practical matter most of the bits defined for QUERY (in [ibid]) are
  195.    identically defined by the other opcodes.  UPDATE uses only one flag
  196.    bit (QR).
  197.  
  198.    The DNS Message Format specifies record counts for its four sections
  199.    (Question, Answer, Authority, and Additional).  UPDATE uses the same
  200.    fields, and the same section formats, but the naming and use of these
  201.    sections differs as shown in the following modified header, after
  202.    [RFC1035 4.1.1]:
  203.  
  204.                                       1  1  1  1  1  1
  205.         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  206.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  207.       |                      ID                       |
  208.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  209.       |QR|   Opcode  |          Z         |   RCODE   |
  210.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  211.       |                    ZOCOUNT                    |
  212.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  213.       |                    PRCOUNT                    |
  214.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  215.       |                    UPCOUNT                    |
  216.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  217.       |                    ADCOUNT                    |
  218.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Vixie, et. al.              Standards Track                     [Page 4]
  227.  
  228. RFC 2136                       DNS Update                     April 1997
  229.  
  230.  
  231.    These fields are used as follows:
  232.  
  233.    ID      A 16-bit identifier assigned by the entity that generates any
  234.            kind of request.  This identifier is copied in the
  235.            corresponding reply and can be used by the requestor to match
  236.            replies to outstanding requests, or by the server to detect
  237.            duplicated requests from some requestor.
  238.  
  239.    QR      A one bit field that specifies whether this message is a
  240.            request (0), or a response (1).
  241.  
  242.    Opcode  A four bit field that specifies the kind of request in this
  243.            message.  This value is set by the originator of a request
  244.            and copied into the response.  The Opcode value that
  245.            identifies an UPDATE message is five (5).
  246.  
  247.    Z       Reserved for future use.  Should be zero (0) in all requests
  248.            and responses.  A non-zero Z field should be ignored by
  249.            implementations of this specification.
  250.  
  251.    RCODE   Response code - this four bit field is undefined in requests
  252.            and set in responses.  The values and meanings of this field
  253.            within responses are as follows:
  254.  
  255.               Mneumonic   Value   Description
  256.               ------------------------------------------------------------
  257.               NOERROR     0       No error condition.
  258.               FORMERR     1       The name server was unable to interpret
  259.                                   the request due to a format error.
  260.               SERVFAIL    2       The name server encountered an internal
  261.                                   failure while processing this request,
  262.                                   for example an operating system error
  263.                                   or a forwarding timeout.
  264.               NXDOMAIN    3       Some name that ought to exist,
  265.                                   does not exist.
  266.               NOTIMP      4       The name server does not support
  267.                                   the specified Opcode.
  268.               REFUSED     5       The name server refuses to perform the
  269.                                   specified operation for policy or
  270.                                   security reasons.
  271.               YXDOMAIN    6       Some name that ought not to exist,
  272.                                   does exist.
  273.               YXRRSET     7       Some RRset that ought not to exist,
  274.                                   does exist.
  275.               NXRRSET     8       Some RRset that ought to exist,
  276.                                   does not exist.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Vixie, et. al.              Standards Track                     [Page 5]
  283.  
  284. RFC 2136                       DNS Update                     April 1997
  285.  
  286.  
  287.               NOTAUTH     9       The server is not authoritative for
  288.                                   the zone named in the Zone Section.
  289.               NOTZONE     10      A name used in the Prerequisite or
  290.                                   Update Section is not within the
  291.                                   zone denoted by the Zone Section.
  292.  
  293.    ZOCOUNT The number of RRs in the Zone Section.
  294.  
  295.    PRCOUNT The number of RRs in the Prerequisite Section.
  296.  
  297.    UPCOUNT The number of RRs in the Update Section.
  298.  
  299.    ADCOUNT The number of RRs in the Additional Data Section.
  300.  
  301.    2.3 - Zone Section
  302.  
  303.    The Zone Section has the same format as that specified in [RFC1035
  304.    4.1.2], with the fields redefined as follows:
  305.  
  306.                                       1  1  1  1  1  1
  307.         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  308.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  309.       |                                               |
  310.       /                     ZNAME                     /
  311.       /                                               /
  312.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  313.       |                     ZTYPE                     |
  314.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  315.       |                     ZCLASS                    |
  316.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  317.  
  318.    UPDATE uses this section to denote the zone of the records being
  319.    updated.  All records to be updated must be in the same zone, and
  320.    therefore the Zone Section is allowed to contain exactly one record.
  321.    The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
  322.    the zone's class.
  323.  
  324.    2.4 - Prerequisite Section
  325.  
  326.    This section contains a set of RRset prerequisites which must be
  327.    satisfied at the time the UPDATE packet is received by the primary
  328.    master server.  The format of this section is as specified by
  329.    [RFC1035 4.1.3].  There are five possible sets of semantics that can
  330.    be expressed here, summarized as follows and then explained below.
  331.  
  332.       (1)  RRset exists (value independent).  At least one RR with a
  333.            specified NAME and TYPE (in the zone and class specified by
  334.            the Zone Section) must exist.
  335.  
  336.  
  337.  
  338. Vixie, et. al.              Standards Track                     [Page 6]
  339.  
  340. RFC 2136                       DNS Update                     April 1997
  341.  
  342.  
  343.       (2)  RRset exists (value dependent).  A set of RRs with a
  344.            specified NAME and TYPE exists and has the same members
  345.            with the same RDATAs as the RRset specified here in this
  346.            Section.
  347.  
  348.       (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
  349.           (in the zone and class denoted by the Zone Section) can exist.
  350.  
  351.       (4)  Name is in use.  At least one RR with a specified NAME (in
  352.            the zone and class specified by the Zone Section) must exist.
  353.            Note that this prerequisite is NOT satisfied by empty
  354.            nonterminals.
  355.  
  356.       (5)  Name is not in use.  No RR of any type is owned by a
  357.            specified NAME.  Note that this prerequisite IS satisfied by
  358.            empty nonterminals.
  359.  
  360.    The syntax of these is as follows:
  361.  
  362.    2.4.1 - RRset Exists (Value Independent)
  363.  
  364.    At least one RR with a specified NAME and TYPE (in the zone and class
  365.    specified in the Zone Section) must exist.
  366.  
  367.    For this prerequisite, a requestor adds to the section a single RR
  368.    whose NAME and TYPE are equal to that of the zone RRset whose
  369.    existence is required.  RDLENGTH is zero and RDATA is therefore
  370.    empty.  CLASS must be specified as ANY to differentiate this
  371.    condition from that of an actual RR whose RDLENGTH is naturally zero
  372.    (0) (e.g., NULL).  TTL is specified as zero (0).
  373.  
  374.    2.4.2 - RRset Exists (Value Dependent)
  375.  
  376.    A set of RRs with a specified NAME and TYPE exists and has the same
  377.    members with the same RDATAs as the RRset specified here in this
  378.    section.  While RRset ordering is undefined and therefore not
  379.    significant to this comparison, the sets be identical in their
  380.    extent.
  381.  
  382.    For this prerequisite, a requestor adds to the section an entire
  383.    RRset whose preexistence is required.  NAME and TYPE are that of the
  384.    RRset being denoted.  CLASS is that of the zone.  TTL must be
  385.    specified as zero (0) and is ignored when comparing RRsets for
  386.    identity.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Vixie, et. al.              Standards Track                     [Page 7]
  395.  
  396. RFC 2136                       DNS Update                     April 1997
  397.  
  398.  
  399.    2.4.3 - RRset Does Not Exist
  400.  
  401.    No RRs with a specified NAME and TYPE (in the zone and class denoted
  402.    by the Zone Section) can exist.
  403.  
  404.    For this prerequisite, a requestor adds to the section a single RR
  405.    whose NAME and TYPE are equal to that of the RRset whose nonexistence
  406.    is required.  The RDLENGTH of this record is zero (0), and RDATA
  407.    field is therefore empty.  CLASS must be specified as NONE in order
  408.    to distinguish this condition from a valid RR whose RDLENGTH is
  409.    naturally zero (0) (for example, the NULL RR).  TTL must be specified
  410.    as zero (0).
  411.  
  412.    2.4.4 - Name Is In Use
  413.  
  414.    Name is in use.  At least one RR with a specified NAME (in the zone
  415.    and class specified by the Zone Section) must exist.  Note that this
  416.    prerequisite is NOT satisfied by empty nonterminals.
  417.  
  418.    For this prerequisite, a requestor adds to the section a single RR
  419.    whose NAME is equal to that of the name whose ownership of an RR is
  420.    required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
  421.    be specified as ANY to differentiate this condition from that of an
  422.    actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
  423.    must be specified as ANY to differentiate this case from that of an
  424.    RRset existence test.  TTL is specified as zero (0).
  425.  
  426.    2.4.5 - Name Is Not In Use
  427.  
  428.    Name is not in use.  No RR of any type is owned by a specified NAME.
  429.    Note that this prerequisite IS satisfied by empty nonterminals.
  430.  
  431.    For this prerequisite, a requestor adds to the section a single RR
  432.    whose NAME is equal to that of the name whose nonownership of any RRs
  433.    is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
  434.    must be specified as NONE.  TYPE must be specified as ANY.  TTL must
  435.    be specified as zero (0).
  436.  
  437.    2.5 - Update Section
  438.  
  439.    This section contains RRs to be added to or deleted from the zone.
  440.    The format of this section is as specified by [RFC1035 4.1.3].  There
  441.    are four possible sets of semantics, summarized below and with
  442.    details to follow.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Vixie, et. al.              Standards Track                     [Page 8]
  451.  
  452. RFC 2136                       DNS Update                     April 1997
  453.  
  454.  
  455.       (1) Add RRs to an RRset.
  456.       (2) Delete an RRset.
  457.       (3) Delete all RRsets from a name.
  458.       (4) Delete an RR from an RRset.
  459.  
  460.    The syntax of these is as follows:
  461.  
  462.    2.5.1 - Add To An RRset
  463.  
  464.    RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
  465.    and RDATA are those being added, and CLASS is the same as the zone
  466.    class.  Any duplicate RRs will be silently ignored by the primary
  467.    master.
  468.  
  469.    2.5.2 - Delete An RRset
  470.  
  471.    One RR is added to the Update Section whose NAME and TYPE are those
  472.    of the RRset to be deleted.  TTL must be specified as zero (0) and is
  473.    otherwise not used by the primary master.  CLASS must be specified as
  474.    ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
  475.    If no such RRset exists, then this Update RR will be silently ignored
  476.    by the primary master.
  477.  
  478.    2.5.3 - Delete All RRsets From A Name
  479.  
  480.    One RR is added to the Update Section whose NAME is that of the name
  481.    to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
  482.    be specified as zero (0) and is otherwise not used by the primary
  483.    master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
  484.    and RDATA must therefore be empty.  If no such RRsets exist, then
  485.    this Update RR will be silently ignored by the primary master.
  486.  
  487.    2.5.4 - Delete An RR From An RRset
  488.  
  489.    RRs to be deleted are added to the Update Section.  The NAME, TYPE,
  490.    RDLENGTH and RDATA must match the RR being deleted.  TTL must be
  491.    specified as zero (0) and will otherwise be ignored by the primary
  492.    master.  CLASS must be specified as NONE to distinguish this from an
  493.    RR addition.  If no such RRs exist, then this Update RR will be
  494.    silently ignored by the primary master.
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Vixie, et. al.              Standards Track                     [Page 9]
  507.  
  508. RFC 2136                       DNS Update                     April 1997
  509.  
  510.  
  511.    2.6 - Additional Data Section
  512.  
  513.    This section contains RRs which are related to the update itself, or
  514.    to new RRs being added by the update.  For example, out of zone glue
  515.    (A RRs referred to by new NS RRs) should be presented here.  The
  516.    server can use or ignore out of zone glue, at the discretion of the
  517.    server implementor.  The format of this section is as specified by
  518.    [RFC1035 4.1.3].
  519.  
  520. 3 - Server Behavior
  521.  
  522.    A server, upon receiving an UPDATE request, will signal NOTIMP to the
  523.    requestor if the UPDATE opcode is not recognized or if it is
  524.    recognized but has not been implemented.  Otherwise, processing
  525.    continues as follows.
  526.  
  527.    3.1 - Process Zone Section
  528.  
  529.    3.1.1. The Zone Section is checked to see that there is exactly one
  530.    RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
  531.    requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
  532.    so named is one of this server's authority zones, else signal NOTAUTH
  533.    to the requestor.  If the server is a zone slave, the request will be
  534.    forwarded toward the primary master.
  535.  
  536.    3.1.2 - Pseudocode For Zone Section Processing
  537.  
  538.       if (zcount != 1 || ztype != SOA)
  539.            return (FORMERR)
  540.       if (zone_type(zname, zclass) == SLAVE)
  541.            return forward()
  542.       if (zone_type(zname, zclass) == MASTER)
  543.            return update()
  544.       return (NOTAUTH)
  545.  
  546.    Sections 3.2 through 3.8 describe the primary master's behaviour,
  547.    whereas Section 6 describes a forwarder's behaviour.
  548.  
  549.    3.2 - Process Prerequisite Section
  550.  
  551.    Next, the Prerequisite Section is checked to see that all
  552.    prerequisites are satisfied by the current state of the zone.  Using
  553.    the definitions expressed in Section 1.2, if any RR's NAME is not
  554.    within the zone specified in the Zone Section, signal NOTZONE to the
  555.    requestor.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Vixie, et. al.              Standards Track                    [Page 10]
  563.  
  564. RFC 2136                       DNS Update                     April 1997
  565.  
  566.  
  567.    3.2.1. For RRs in this section whose CLASS is ANY, test to see that
  568.    TTL and RDLENGTH are both zero (0), else signal FORMERR to the
  569.    requestor.  If TYPE is ANY, test to see that there is at least one RR
  570.    in the zone whose NAME is the same as that of the Prerequisite RR,
  571.    else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
  572.    see that there is at least one RR in the zone whose NAME and TYPE are
  573.    the same as that of the Prerequisite RR, else signal NXRRSET to the
  574.    requestor.
  575.  
  576.    3.2.2. For RRs in this section whose CLASS is NONE, test to see that
  577.    the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
  578.    requestor.  If the TYPE is ANY, test to see that there are no RRs in
  579.    the zone whose NAME is the same as that of the Prerequisite RR, else
  580.    signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
  581.    see that there are no RRs in the zone whose NAME and TYPE are the
  582.    same as that of the Prerequisite RR, else signal YXRRSET to the
  583.    requestor.
  584.  
  585.    3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
  586.    test to see that the TTL is zero (0), else signal FORMERR to the
  587.    requestor.  Then, build an RRset for each unique <NAME,TYPE> and
  588.    compare each resulting RRset for set equality (same members, no more,
  589.    no less) with RRsets in the zone.  If any Prerequisite RRset is not
  590.    entirely and exactly matched by a zone RRset, signal NXRRSET to the
  591.    requestor.  If any RR in this section has a CLASS other than ZCLASS
  592.    or NONE or ANY, signal FORMERR to the requestor.
  593.  
  594.    3.2.4 - Table Of Metavalues Used In Prerequisite Section
  595.  
  596.    CLASS    TYPE     RDATA    Meaning
  597.    ------------------------------------------------------------
  598.    ANY      ANY      empty    Name is in use
  599.    ANY      rrset    empty    RRset exists (value independent)
  600.    NONE     ANY      empty    Name is not in use
  601.    NONE     rrset    empty    RRset does not exist
  602.    zone     rrset    rr       RRset exists (value dependent)
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Vixie, et. al.              Standards Track                    [Page 11]
  619.  
  620. RFC 2136                       DNS Update                     April 1997
  621.  
  622.  
  623.    3.2.5 - Pseudocode for Prerequisite Section Processing
  624.  
  625.       for rr in prerequisites
  626.            if (rr.ttl != 0)
  627.                 return (FORMERR)
  628.            if (zone_of(rr.name) != ZNAME)
  629.                 return (NOTZONE);
  630.            if (rr.class == ANY)
  631.                 if (rr.rdlength != 0)
  632.                      return (FORMERR)
  633.                 if (rr.type == ANY)
  634.                      if (!zone_name<rr.name>)
  635.                           return (NXDOMAIN)
  636.                 else
  637.                      if (!zone_rrset<rr.name, rr.type>)
  638.                           return (NXRRSET)
  639.            if (rr.class == NONE)
  640.                 if (rr.rdlength != 0)
  641.                      return (FORMERR)
  642.                 if (rr.type == ANY)
  643.                      if (zone_name<rr.name>)
  644.                           return (YXDOMAIN)
  645.                 else
  646.                      if (zone_rrset<rr.name, rr.type>)
  647.                           return (YXRRSET)
  648.            if (rr.class == zclass)
  649.                 temp<rr.name, rr.type> += rr
  650.            else
  651.                 return (FORMERR)
  652.  
  653.       for rrset in temp
  654.            if (zone_rrset<rrset.name, rrset.type> != rrset)
  655.                 return (NXRRSET)
  656.  
  657.    3.3 - Check Requestor's Permissions
  658.  
  659.    3.3.1. Next, the requestor's permission to update the RRs named in
  660.    the Update Section may be tested in an implementation dependent
  661.    fashion or using mechanisms specified in a subsequent Secure DNS
  662.    Update protocol.  If the requestor does not have permission to
  663.    perform these updates, the server may write a warning message in its
  664.    operations log, and may either signal REFUSED to the requestor, or
  665.    ignore the permission problem and proceed with the update.
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Vixie, et. al.              Standards Track                    [Page 12]
  675.  
  676. RFC 2136                       DNS Update                     April 1997
  677.  
  678.  
  679.    3.3.2. While the exact processing is implementation defined, if these
  680.    verification activities are to be performed, this is the point in the
  681.    server's processing where such performance should take place, since
  682.    if a REFUSED condition is encountered after an update has been
  683.    partially applied, it will be necessary to undo the partial update
  684.    and restore the zone to its original state before answering the
  685.    requestor.
  686.  
  687.    3.3.3 - Pseudocode for Permission Checking
  688.  
  689.       if (security policy exists)
  690.            if (this update is not permitted)
  691.                 if (local option)
  692.                      log a message about permission problem
  693.                 if (local option)
  694.                      return (REFUSED)
  695.  
  696.    3.4 - Process Update Section
  697.  
  698.    Next, the Update Section is processed as follows.
  699.  
  700.    3.4.1 - Prescan
  701.  
  702.    The Update Section is parsed into RRs and each RR's CLASS is checked
  703.    to see if it is ANY, NONE, or the same as the Zone Class, else signal
  704.    a FORMERR to the requestor.  Using the definitions in Section 1.2,
  705.    each RR's NAME must be in the zone specified by the Zone Section,
  706.    else signal NOTZONE to the requestor.
  707.  
  708.    3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
  709.    ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
  710.    unrecognized type, then signal FORMERR to the requestor.  For RRs
  711.    whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
  712.    else signal a FORMERR to the requestor.  For any RR whose CLASS is
  713.    ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
  714.    the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
  715.    MAILB, or any other QUERY metatype besides ANY, or any unrecognized
  716.    type, else signal FORMERR to the requestor.
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Vixie, et. al.              Standards Track                    [Page 13]
  731.  
  732. RFC 2136                       DNS Update                     April 1997
  733.  
  734.  
  735.    3.4.1.3 - Pseudocode For Update Section Prescan
  736.  
  737.       [rr] for rr in updates
  738.            if (zone_of(rr.name) != ZNAME)
  739.                 return (NOTZONE);
  740.            if (rr.class == zclass)
  741.                 if (rr.type & ANY|AXFR|MAILA|MAILB)
  742.                      return (FORMERR)
  743.            elsif (rr.class == ANY)
  744.                 if (rr.ttl != 0 || rr.rdlength != 0
  745.                     || rr.type & AXFR|MAILA|MAILB)
  746.                      return (FORMERR)
  747.            elsif (rr.class == NONE)
  748.                 if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
  749.                      return (FORMERR)
  750.            else
  751.                 return (FORMERR)
  752.  
  753.    3.4.2 - Update
  754.  
  755.    The Update Section is parsed into RRs and these RRs are processed in
  756.    order.
  757.  
  758.    3.4.2.1. If any system failure (such as an out of memory condition,
  759.    or a hardware error in persistent storage) occurs during the
  760.    processing of this section, signal SERVFAIL to the requestor and undo
  761.    all updates applied to the zone during this transaction.
  762.  
  763.    3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
  764.    the zone.  In case of duplicate RDATAs (which for SOA RRs is always
  765.    the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
  766.    fields both match), the Zone RR is replaced by Update RR.  If the
  767.    TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
  768.    lower (according to [RFC1982]) than or equal to the current Zone SOA
  769.    RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
  770.    Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
  771.    Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
  772.    RR.
  773.  
  774.    3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
  775.    all Zone RRs with the same NAME are deleted, unless the NAME is the
  776.    same as ZNAME in which case only those RRs whose TYPE is other than
  777.    SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
  778.    whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
  779.    deleted, unless the NAME is the same as ZNAME in which case neither
  780.    SOA or NS RRs will be deleted.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Vixie, et. al.              Standards Track                    [Page 14]
  787.  
  788. RFC 2136                       DNS Update                     April 1997
  789.  
  790.  
  791.    3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
  792.    NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
  793.    unless the NAME is the same as ZNAME and either the TYPE is SOA or
  794.    the TYPE is NS and the matching Zone RR is the only NS remaining in
  795.    the RRset, in which case this Update RR is ignored.
  796.  
  797.    3.4.2.5. Signal NOERROR to the requestor.
  798.  
  799.    3.4.2.6 - Table Of Metavalues Used In Update Section
  800.  
  801.    CLASS    TYPE     RDATA    Meaning
  802.    ---------------------------------------------------------
  803.    ANY      ANY      empty    Delete all RRsets from a name
  804.    ANY      rrset    empty    Delete an RRset
  805.    NONE     rrset    rr       Delete an RR from an RRset
  806.    zone     rrset    rr       Add to an RRset
  807.  
  808.    3.4.2.7 - Pseudocode For Update Section Processing
  809.  
  810.       [rr] for rr in updates
  811.            if (rr.class == zclass)
  812.                 if (rr.type == CNAME)
  813.                      if (zone_rrset<rr.name, ~CNAME>)
  814.                           next [rr]
  815.                 elsif (zone_rrset<rr.name, CNAME>)
  816.                      next [rr]
  817.                 if (rr.type == SOA)
  818.                      if (!zone_rrset<rr.name, SOA> ||
  819.                          zone_rr<rr.name, SOA>.serial > rr.soa.serial)
  820.                           next [rr]
  821.                 for zrr in zone_rrset<rr.name, rr.type>
  822.                      if (rr.type == CNAME || rr.type == SOA ||
  823.                          (rr.type == WKS && rr.proto == zrr.proto &&
  824.                           rr.address == zrr.address) ||
  825.                          rr.rdata == zrr.rdata)
  826.                           zrr = rr
  827.                           next [rr]
  828.                 zone_rrset<rr.name, rr.type> += rr
  829.            elsif (rr.class == ANY)
  830.                 if (rr.type == ANY)
  831.                      if (rr.name == zname)
  832.                           zone_rrset<rr.name, ~(SOA|NS)> = Nil
  833.                      else
  834.                           zone_rrset<rr.name, *> = Nil
  835.                 elsif (rr.name == zname &&
  836.                        (rr.type == SOA || rr.type == NS))
  837.                      next [rr]
  838.                 else
  839.  
  840.  
  841.  
  842. Vixie, et. al.              Standards Track                    [Page 15]
  843.  
  844. RFC 2136                       DNS Update                     April 1997
  845.  
  846.  
  847.                      zone_rrset<rr.name, rr.type> = Nil
  848.            elsif (rr.class == NONE)
  849.                 if (rr.type == SOA)
  850.                      next [rr]
  851.                 if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
  852.                      next [rr]
  853.                 zone_rr<rr.name, rr.type, rr.data> = Nil
  854.       return (NOERROR)
  855.  
  856.    3.5 - Stability
  857.  
  858.    When a zone is modified by an UPDATE operation, the server must
  859.    commit the change to nonvolatile storage before sending a response to
  860.    the requestor or answering any queries or transfers for the modified
  861.    zone.  It is reasonable for a server to store only the update records
  862.    as long as a system reboot or power failure will cause these update
  863.    records to be incorporated into the zone the next time the server is
  864.    started.  It is also reasonable for the server to copy the entire
  865.    modified zone to nonvolatile storage after each update operation,
  866.    though this would have suboptimal performance for large zones.
  867.  
  868.    3.6 - Zone Identity
  869.  
  870.    If the zone's SOA SERIAL is changed by an update operation, that
  871.    change must be in a positive direction (using modulo 2**32 arithmetic
  872.    as specified by [RFC1982]).  Attempts to replace an SOA with one
  873.    whose SERIAL is less than the current one will be silently ignored by
  874.    the primary master server.
  875.  
  876.    If the zone's SOA's SERIAL is not changed as a result of an update
  877.    operation, then the server shall increment it automatically before
  878.    the SOA or any changed name or RR or RRset is included in any
  879.    response or transfer.  The primary master server's implementor might
  880.    choose to autoincrement the SOA SERIAL if any of the following events
  881.    occurs:
  882.  
  883.    (1)  Each update operation.
  884.  
  885.    (2)  A name, RR or RRset in the zone has changed and has subsequently
  886.         been visible to a DNS client since the unincremented SOA was
  887.         visible to a DNS client, and the SOA is about to become visible
  888.         to a DNS client.
  889.  
  890.    (3)  A configurable period of time has elapsed since the last update
  891.         operation.  This period shall be less than or equal to one third
  892.         of the zone refresh time, and the default shall be the lesser of
  893.         that maximum and 300 seconds.
  894.  
  895.  
  896.  
  897.  
  898. Vixie, et. al.              Standards Track                    [Page 16]
  899.  
  900. RFC 2136                       DNS Update                     April 1997
  901.  
  902.  
  903.    (4)  A configurable number of updates has been applied since the last
  904.         SOA change.  The default value for this configuration parameter
  905.         shall be one hundred (100).
  906.  
  907.    It is imperative that the zone's contents and the SOA's SERIAL be
  908.    tightly synchronized.  If the zone appears to change, the SOA must
  909.    appear to change as well.
  910.  
  911.    3.7 - Atomicity
  912.  
  913.    During the processing of an UPDATE transaction, the server must
  914.    ensure atomicity with respect to other (concurrent) UPDATE or QUERY
  915.    transactions.  No two transactions can be processed concurrently if
  916.    either depends on the final results of the other; in particular, a
  917.    QUERY should not be able to retrieve RRsets which have been partially
  918.    modified by a concurrent UPDATE, and an UPDATE should not be able to
  919.    start from prerequisites that might not still hold at the completion
  920.    of some other concurrent UPDATE.  Finally, if two UPDATE transactions
  921.    would modify the same names, RRs or RRsets, then such UPDATE
  922.    transactions must be serialized.
  923.  
  924.    3.8 - Response
  925.  
  926.    At the end of UPDATE processing, a response code will be known.  A
  927.    response message is generated by copying the ID and Opcode fields
  928.    from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
  929.    and ADCOUNT fields and associated sections, or placing zeros (0) in
  930.    the these "count" fields and not including any part of the original
  931.    update.  The QR bit is set to one (1), and the response is sent back
  932.    to the requestor.  If the requestor used UDP, then the response will
  933.    be sent to the requestor's source UDP port.  If the requestor used
  934.    TCP, then the response will be sent back on the requestor's open TCP
  935.    connection.
  936.  
  937. 4 - Requestor Behaviour
  938.  
  939.    4.1. From a requestor's point of view, any authoritative server for
  940.    the zone can appear to be able to process update requests, even
  941.    though only the primary master server is actually able to modify the
  942.    zone's master file.  Requestors are expected to know the name of the
  943.    zone they intend to update and to know or be able to determine the
  944.    name servers for that zone.
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Vixie, et. al.              Standards Track                    [Page 17]
  955.  
  956. RFC 2136                       DNS Update                     April 1997
  957.  
  958.  
  959.    4.2. If update ordering is desired, the requestor will need to know
  960.    the value of the existing SOA RR.  Requestors who update the SOA RR
  961.    must update the SOA SERIAL field in a positive direction (as defined
  962.    by [RFC1982]) and also preserve the other SOA fields unless the
  963.    requestor's explicit intent is to change them.  The SOA SERIAL field
  964.    must never be set to zero (0).
  965.  
  966.    4.3. If the requestor has reasonable cause to believe that all of a
  967.    zone's servers will be equally reachable, then it should arrange to
  968.    try the primary master server (as given by the SOA MNAME field if
  969.    matched by some NS NSDNAME) first to avoid unnecessary forwarding
  970.    inside the slave servers.  (Note that the primary master will in some
  971.    cases not be reachable by all requestors, due to firewalls or network
  972.    partitioning.)
  973.  
  974.    4.4. Once the zone's name servers been found and possibly sorted so
  975.    that the ones more likely to be reachable and/or support the UPDATE
  976.    opcode are listed first, the requestor composes an UPDATE message of
  977.    the following form and sends it to the first name server on its list:
  978.  
  979.       ID:                        (new)
  980.       Opcode:                    UPDATE
  981.       Zone zcount:               1
  982.       Zone zname:                (zone name)
  983.       Zone zclass:               (zone class)
  984.       Zone ztype:                T_SOA
  985.       Prerequisite Section:      (see previous text)
  986.       Update Section:            (see previous text)
  987.       Additional Data Section:   (empty)
  988.  
  989.    4.5. If the requestor receives a response, and the response has an
  990.    RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
  991.    appropriate response to its caller.
  992.  
  993.    4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
  994.    if no response is received within an implementation dependent timeout
  995.    period, or if an ICMP error is received indicating that the server's
  996.    port is unreachable, then the requestor will delete the unusable
  997.    server from its internal name server list and try the next one,
  998.    repeating until the name server list is empty.  If the requestor runs
  999.    out of servers to try, an appropriate error will be returned to the
  1000.    requestor's caller.
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Vixie, et. al.              Standards Track                    [Page 18]
  1011.  
  1012. RFC 2136                       DNS Update                     April 1997
  1013.  
  1014.  
  1015. 5 - Duplicate Detection, Ordering and Mutual Exclusion
  1016.  
  1017.    5.1. For correct operation, mechanisms may be needed to ensure
  1018.    idempotence, order UPDATE requests and provide mutual exclusion.  An
  1019.    UPDATE message or response might be delivered zero times, one time,
  1020.    or multiple times.  Datagram duplication is of particular interest
  1021.    since it covers the case of the so-called "replay attack" where a
  1022.    correct request is duplicated maliciously by an intruder.
  1023.  
  1024.    5.2. Multiple UPDATE requests or responses in transit might be
  1025.    delivered in any order, due to network topology changes or load
  1026.    balancing, or to multipath forwarding graphs wherein several slave
  1027.    servers all forward to the primary master.  In some cases, it might
  1028.    be required that the earlier update not be applied after the later
  1029.    update, where "earlier" and "later" are defined by an external time
  1030.    base visible to some set of requestors, rather than by the order of
  1031.    request receipt at the primary master.
  1032.  
  1033.    5.3. A requestor can ensure transaction idempotence by explicitly
  1034.    deleting some "marker RR" (rather than deleting the RRset of which it
  1035.    is a part) and then adding a new "marker RR" with a different RDATA
  1036.    field.  The Prerequisite Section should specify that the original
  1037.    "marker RR" must be present in order for this UPDATE message to be
  1038.    accepted by the server.
  1039.  
  1040.    5.4. If the request is duplicated by a network error, all duplicate
  1041.    requests will fail since only the first will find the original
  1042.    "marker RR" present and having its known previous value.  The
  1043.    decisions of whether to use such a "marker RR" and what RR to use are
  1044.    left up to the application programmer, though one obvious choice is
  1045.    the zone's SOA RR as described below.
  1046.  
  1047.    5.5. Requestors can ensure update ordering by externally
  1048.    synchronizing their use of successive values of the "marker RR."
  1049.    Mutual exclusion can be addressed as a degenerate case, in that a
  1050.    single succession of the "marker RR" is all that is needed.
  1051.  
  1052.    5.6. A special case where update ordering and datagram duplication
  1053.    intersect is when an RR validly changes to some new value and then
  1054.    back to its previous value.  Without a "marker RR" as described
  1055.    above, this sequence of updates can leave the zone in an undefined
  1056.    state if datagrams are duplicated.
  1057.  
  1058.    5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
  1059.    a requestor could first retrieve the SOA RR, and build an UPDATE
  1060.    message one of whose prerequisites was the old SOA RR.  It would then
  1061.    specify updates that would delete this SOA RR and add a new one with
  1062.    an incremented SOA SERIAL, along with whatever actual prerequisites
  1063.  
  1064.  
  1065.  
  1066. Vixie, et. al.              Standards Track                    [Page 19]
  1067.  
  1068. RFC 2136                       DNS Update                     April 1997
  1069.  
  1070.  
  1071.    and updates were the object of the transaction.  If the transaction
  1072.    succeeds, the requestor knows that the RRs being changed were not
  1073.    otherwise altered by any other requestor.
  1074.  
  1075. 6 - Forwarding
  1076.  
  1077.    When a zone slave forwards an UPDATE message upward toward the zone's
  1078.    primary master server, it must allocate a new ID and prepare to enter
  1079.    the role of "forwarding server," which is a requestor with respect to
  1080.    the forward server.
  1081.  
  1082.    6.1. The set of forward servers will be same as the set of servers
  1083.    this zone slave would use as the source of AXFR or IXFR data.  So,
  1084.    while the original requestor might have used the zone's NS RRset to
  1085.    locate its update server, a forwarder always forwards toward its
  1086.    designated zone master servers.
  1087.  
  1088.    6.2. If the original requestor used TCP, then the TCP connection from
  1089.    the requestor is still open and the forwarder must use TCP to forward
  1090.    the message.  If the original requestor used UDP, the forwarder may
  1091.    use either UDP or TCP to forward the message, at the whim of the
  1092.    implementor.
  1093.  
  1094.    6.3. It is reasonable for forward servers to be forwarders
  1095.    themselves, if the AXFR dependency graph being followed is a deep one
  1096.    involving firewalls and multiple connectivity realms.  In most cases
  1097.    the AXFR dependency graph will be shallow and the forward server will
  1098.    be the primary master server.
  1099.  
  1100.    6.4. The forwarder will not respond to its requestor until it
  1101.    receives a response from its forward server.  UPDATE transactions
  1102.    involving forwarders are therefore time synchronized with respect to
  1103.    the original requestor and the primary master server.
  1104.  
  1105.    6.5. When there are multiple possible sources of AXFR data and
  1106.    therefore multiple possible forward servers, a forwarder will use the
  1107.    same fallback strategy with respect to connectivity or timeout errors
  1108.    that it would use when performing an AXFR.  This is implementation
  1109.    dependent.
  1110.  
  1111.    6.6. When a forwarder receives a response from a forward server, it
  1112.    copies this response into a new response message, assigns its
  1113.    requestor's ID to that message, and sends the response back to the
  1114.    requestor.
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Vixie, et. al.              Standards Track                    [Page 20]
  1123.  
  1124. RFC 2136                       DNS Update                     April 1997
  1125.  
  1126.  
  1127. 7 - Design, Implementation, Operation, and Protocol Notes
  1128.  
  1129.    Some of the principles which guided the design of this UPDATE
  1130.    specification are as follows.  Note that these are not part of the
  1131.    formal specification and any disagreement between this section and
  1132.    any other section of this document should be resolved in favour of
  1133.    the other section.
  1134.  
  1135.    7.1. Using metavalues for CLASS is possible only because all RRs in
  1136.    the packet are assumed to be in the same zone, and CLASS is an
  1137.    attribute of a zone rather than of an RRset.  (It is for this reason
  1138.    that the Zone Section is not optional.)
  1139.  
  1140.    7.2. Since there are no data-present or data-absent errors possible
  1141.    from processing the Update Section, any necessary data-present and
  1142.    data- absent dependencies should be specified in the Prerequisite
  1143.    Section.
  1144.  
  1145.    7.3. The Additional Data Section can be used to supply a server with
  1146.    out of zone glue that will be needed in referrals.  For example, if
  1147.    adding a new NS RR to HOME.VIX.COM specifying a nameserver called
  1148.    NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
  1149.    Data Section.  Servers can use this information or ignore it, at the
  1150.    discretion of the implementor.  We discourage caching this
  1151.    information for use in subsequent DNS responses.
  1152.  
  1153.    7.4. The Additional Data Section might be used if some of the RRs
  1154.    later needed for Secure DNS Update are not actually zone updates, but
  1155.    rather ancillary keys or signatures not intended to be stored in the
  1156.    zone (as an update would be), yet necessary for validating the update
  1157.    operation.
  1158.  
  1159.    7.5. It is expected that in the absence of Secure DNS Update, a
  1160.    server will only accept updates if they come from a source address
  1161.    that has been statically configured in the server's description of a
  1162.    primary master zone.  DHCP servers would be likely candidates for
  1163.    inclusion in this statically configured list.
  1164.  
  1165.    7.6. It is not possible to create a zone using this protocol, since
  1166.    there is no provision for a slave server to be told who its master
  1167.    servers are.  It is expected that this protocol will be extended in
  1168.    the future to cover this case.  Therefore, at this time, the addition
  1169.    of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
  1170.    is also unsupported.
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Vixie, et. al.              Standards Track                    [Page 21]
  1179.  
  1180. RFC 2136                       DNS Update                     April 1997
  1181.  
  1182.  
  1183.    7.7. The prerequisite for specifying that a name own at least one RR
  1184.    differs semantically from QUERY, in that QUERY would return
  1185.    <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
  1186.    this name, while UPDATE's prerequisite condition [Section 2.4.4]
  1187.    would NOT be satisfied.
  1188.  
  1189.    7.8. It is possible for a UDP response to be lost in transit and for
  1190.    a request to be retried due to a timeout condition.  In this case an
  1191.    UPDATE that was successful the first time it was received by the
  1192.    primary master might ultimately appear to have failed when the
  1193.    response to a duplicate request is finally received by the requestor.
  1194.    (This is because the original prerequisites may no longer be
  1195.    satisfied after the update has been applied.)  For this reason,
  1196.    requestors who require an accurate response code must use TCP.
  1197.  
  1198.    7.9. Because a requestor who requires an accurate response code will
  1199.    initiate their UPDATE transaction using TCP, a forwarder who receives
  1200.    a request via TCP must forward it using TCP.
  1201.  
  1202.    7.10. Deferral of SOA SERIAL autoincrements is made possible so that
  1203.    serial numbers can be conserved and wraparound at 2**32 can be made
  1204.    an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
  1205.    to differ if the zone differs.  Note that the Authority Section SOA
  1206.    in a QUERY response is a form of visibility, for the purposes of this
  1207.    prerequisite.
  1208.  
  1209.    7.11. A zone's SOA SERIAL should never be set to zero (0) due to
  1210.    interoperability problems with some older but widely installed
  1211.    implementations of DNS.  When incrementing an SOA SERIAL, if the
  1212.    result of the increment is zero (0) (as will be true when wrapping
  1213.    around 2**32), it is necessary to increment it again or set it to one
  1214.    (1).  See [RFC1982] for more detail on this subject.
  1215.  
  1216.    7.12. Due to the TTL minimalization necessary when caching an RRset,
  1217.    it is recommended that all TTLs in an RRset be set to the same value.
  1218.    While the DNS Message Format permits variant TTLs to exist in the
  1219.    same RRset, and this variance can exist inside a zone, such variance
  1220.    will have counterintuitive results and its use is discouraged.
  1221.  
  1222.    7.13. Zone cut management presents some obscure corner cases to the
  1223.    add and delete operations in the Update Section.  It is possible to
  1224.    delete an NS RR as long as it is not the last NS RR at the root of a
  1225.    zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
  1226.    a zone are unaffected.  If deleting RRsets, it is not possible to
  1227.    delete either SOA or NS RRsets at the top of a zone.  An attempt to
  1228.    add an SOA will be treated as a replace operation if an SOA already
  1229.    exists, or as a no-op if the SOA would be new.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Vixie, et. al.              Standards Track                    [Page 22]
  1235.  
  1236. RFC 2136                       DNS Update                     April 1997
  1237.  
  1238.  
  1239.    7.14. No semantic checking is required in the primary master server
  1240.    when adding new RRs.  Therefore a requestor can cause CNAME or NS or
  1241.    any other kind of RR to be added even if their target name does not
  1242.    exist or does not have the proper RRsets to make the original RR
  1243.    useful.  Primary master servers that DO implement this kind of
  1244.    checking should take great care to avoid out-of-zone dependencies
  1245.    (whose veracity cannot be authoritatively checked) and should
  1246.    implement all such checking during the prescan phase.
  1247.  
  1248.    7.15. Nonterminal or wildcard CNAMEs are not well specified by
  1249.    [RFC1035] and their use will probably lead to unpredictable results.
  1250.    Their use is discouraged.
  1251.  
  1252.    7.16. Empty nonterminals (nodes with children but no RRs of their
  1253.    own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
  1254.    to a query of any type for that name.  There is no provision for
  1255.    empty terminal nodes -- so if all RRs of a terminal node are deleted,
  1256.    the name is no longer in use, and queries of any type for that name
  1257.    will result in an NXDOMAIN response.
  1258.  
  1259.    7.17. In a deep AXFR dependency graph, it has not historically been
  1260.    an error for slaves to depend mutually upon each other.  This
  1261.    configuration has been used to enable a zone to flow from the primary
  1262.    master to all slaves even though not all slaves have continuous
  1263.    connectivity to the primary master.  UPDATE's use of the AXFR
  1264.    dependency graph for forwarding prohibits this kind of dependency
  1265.    loop, since UPDATE forwarding has no loop detection analagous to the
  1266.    SOA SERIAL pretest used by AXFR.
  1267.  
  1268.    7.18. Previously existing names which are occluded by a new zone cut
  1269.    are still considered part of the parent zone, for the purposes of
  1270.    zone transfers, even though queries for such names will be referred
  1271.    to the new subzone's servers.  If a zone cut is removed, all parent
  1272.    zone names that were occluded by it will again become visible to
  1273.    queries.  (This is a clarification of [RFC1034].)
  1274.  
  1275.    7.19. If a server is authoritative for both a zone and its child,
  1276.    then queries for names at the zone cut between them will be answered
  1277.    authoritatively using only data from the child zone.  (This is a
  1278.    clarification of [RFC1034].)
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Vixie, et. al.              Standards Track                    [Page 23]
  1291.  
  1292. RFC 2136                       DNS Update                     April 1997
  1293.  
  1294.  
  1295.    7.20. Update ordering using the SOA RR is problematic since there is
  1296.    no way to know which of a zone's NS RRs represents the primary
  1297.    master, and the zone slaves can be out of date if their SOA.REFRESH
  1298.    timers have not elapsed since the last time the zone was changed on
  1299.    the primary master.  We recommend that a zone needing ordered updates
  1300.    use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
  1301.    [RFC1995]), and that a client receiving a prerequisite error while
  1302.    attempting an ordered update simply retry after a random delay period
  1303.    to allow the zone to settle.
  1304.  
  1305. 8 - Security Considerations
  1306.  
  1307.    8.1. In the absence of [RFC2137] or equivilent technology, the
  1308.    protocol described by this document makes it possible for anyone who
  1309.    can reach an authoritative name server to alter the contents of any
  1310.    zones on that server.  This is a serious increase in vulnerability
  1311.    from the current technology.  Therefore it is very strongly
  1312.    recommended that the protocols described in this document not be used
  1313.    without [RFC2137] or other equivalently strong security measures,
  1314.    e.g. IPsec.
  1315.  
  1316.    8.2. A denial of service attack can be launched by flooding an update
  1317.    forwarder with TCP sessions containing updates that the primary
  1318.    master server will ultimately refuse due to permission problems.
  1319.    This arises due to the requirement that an update forwarder receiving
  1320.    a request via TCP use a synchronous TCP session for its forwarding
  1321.    operation.  The connection management mechanisms of [RFC1035 4.2.2]
  1322.    are sufficient to prevent large scale damage from such an attack, but
  1323.    not to prevent some queries from going unanswered during the attack.
  1324.  
  1325. Acknowledgements
  1326.  
  1327.    We would like to thank the IETF DNSIND working group for their input
  1328.    and assistance, in particular, Rob Austein, Randy Bush, Donald
  1329.    Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
  1330.    thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
  1331.    document.
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Vixie, et. al.              Standards Track                    [Page 24]
  1347.  
  1348. RFC 2136                       DNS Update                     April 1997
  1349.  
  1350.  
  1351. References
  1352.  
  1353.    [RFC1035]
  1354.       Mockapetris, P., "Domain Names - Implementation and
  1355.       Specification", STD 13, RFC 1035, USC/Information Sciences
  1356.       Institute, November 1987.
  1357.  
  1358.    [RFC1982]
  1359.       Elz, R., "Serial Number Arithmetic", RFC 1982, University of
  1360.       Melbourne, August 1996.
  1361.  
  1362.    [RFC1995]
  1363.       Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
  1364.       of Technology, August 1996.
  1365.  
  1366.    [RFC1996]
  1367.       Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
  1368.       RFC 1996, Internet Software Consortium, August 1996.
  1369.  
  1370.    [RFC2065]
  1371.       Eastlake, D., and C. Kaufman, "Domain Name System Protocol
  1372.       Security Extensions", RFC 2065, January 1997.
  1373.  
  1374.    [RFC2137]
  1375.       Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
  1376.       2137, April 1997.
  1377.  
  1378. Authors' Addresses
  1379.  
  1380.    Yakov Rekhter
  1381.    Cisco Systems
  1382.    170 West Tasman Drive
  1383.    San Jose, CA 95134-1706
  1384.  
  1385.    Phone: +1 914 528 0090
  1386.    EMail: yakov@cisco.com
  1387.  
  1388.  
  1389.    Susan Thomson
  1390.    Bellcore
  1391.    445 South Street
  1392.    Morristown, NJ 07960
  1393.  
  1394.    Phone: +1 201 829 4514
  1395.    EMail: set@thumper.bellcore.com
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Vixie, et. al.              Standards Track                    [Page 25]
  1403.  
  1404. RFC 2136                       DNS Update                     April 1997
  1405.  
  1406.  
  1407.    Jim Bound
  1408.    Digital Equipment Corp.
  1409.    110 Spitbrook Rd ZK3-3/U14
  1410.    Nashua, NH 03062-2698
  1411.  
  1412.    Phone: +1 603 881 0400
  1413.    EMail: bound@zk3.dec.com
  1414.  
  1415.  
  1416.    Paul Vixie
  1417.    Internet Software Consortium
  1418.    Star Route Box 159A
  1419.    Woodside, CA 94062
  1420.  
  1421.    Phone: +1 415 747 0204
  1422.    EMail: paul@vix.com
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Vixie, et. al.              Standards Track                    [Page 26]
  1459.  
  1460.